home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga Tools 5
/
Amiga Tools 5.iso
/
tools
/
shell-tools
/
wbstart
/
xfa_library
/
xfa_library.doc
< prev
next >
Wrap
Text File
|
1996-04-24
|
38KB
|
1,430 lines
------------------------------------------------------------------------------
eXtra Fast Animation Library
XFA.LIBRARY v 1.00
------------------
© ClassX 1995
Concept/Code/Design by Mik
...............................
Written by Michele Puccini
of ClassX
Via Francesca 463
I-56030 Montecalvoli (PI) ITALY
Tel/Fax +39 587 749206
EMail: classx@pisoft.it (Bug-Reports, Comments, Greets)
------------------------------------------------------------------------------
IMPORTANT:
This library is FreeWare, and NOT FOR COMMERCIAL PUPOSES.
If you write an application that makes use of this library, you
are kindly requested to let me know and to give me one copy of
what you've developed.
This library cannot be used for commercial products without written
permission of ClassX Development Italy.
------------------------------------------------------------------------------
Standard Disclaimer
*******************
THERE IS NO WARRANTY FOR THE SOFTWARE TO THE EXTENT PERMITTED BY APPLICABLE
LAW. EXCEPT WHERE OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE SOFTWARE "AS IS" WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE
ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH YOU.
SHOULD THE SOFTWARE PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
SERVICING, REPAIR OR CORRECTION.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL
ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY REDISTRIBUTE THE SOFTWARE
AS PERMITTED BELOW, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL,
SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
INABILITY TO USE THE SOFTWARE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR
DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES
OR A FAILURE OF THE SOFTWARE TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
------------------------------------------------------------------------------
- Another NON-STANDARD animation format, why ?
Well, during the development of X-DVE, our titling/animation system, one of
the first problems I had to face was to choose an animation format suited
for video resolutions (meaning both PAL and NTSC) fast enough to play
smooth, even with high resolution and "deep" screens.
I started to test the various standard animation formats, like Anim-5, Anim-7
etc.
They were all too slow to play and gave other extra features (like multiple
palette handling, multi frame rates, complete multitasking) which I could
stand without.
The only anim format very near to my requirements was SCALA's anim 32I, but:
- there was no documentation for it.
- it was smooth enough, but trying to swith caches off (68040) display
started to flash, making me think of a bad double buffering tecnique.
So, I decided to start working on a new compression tecnique (XFA) that
now is in your hands.
- What kind of tecnique is used in XFA ?
The tecnique is the classic "delta frame compression" that is normally used
for anim-5, anim-7 formats.
XFA animations can be of 4 different kinds:
MODE COMPRESSION DISPLAY NOTE
XFA_MODE16 16 bit ANY(forced to PAL) right for disk play
XFA_MODE32 32 bit ANY(forced to PAL) right for disk play
XFA_MODE16I 16 bit PAL/NTSC Lace
XFA_MODE32I 32 bit PAL/NTSC Lace
While MODE16 and MODE32 can be played from disk and in any screen mode,
MODE16I and MODE32I offers a better compression but can only be played
in PAL or NTSC interlaced screens (this is what I need for VIDEO applications)
The "I" modes are expressely developed to run at 50fps (PAL) and MUST run
at 50fps (the only way to see smooth animations)
The difference from anim-5/7 is that XFA deltas can be decompressed with a
small (can be totally cached), fast and furious asm routine that outperforms
any comparable standard decompression routine.
Another difference is that, for "16I & 32I" modes, only half information
is compressed for each frame, (nearly) doubling the decompression speed and
(nearly) halving the size of each delta.
Displaying XFA "16I & 32I" mode animations, involves some low-level work
with copper lists, in order to achieve a solid double buffering, even when
the CPU is not fast enough to decompress deltas in synch with the vertical
beam.
------------------------------------------------------------------------------
This library has been developed to allow flexible access to XFA animations.
PD programmers are strongly encouraged to use this library as it has a "uman"
programming approach and interesting (I hope) performances.
I Hope to see talented PD programmers using this library for players,
converters and other related applications.
The first application I hope to see in the next months is a complete XFA
datatype (........even if this will not give 50fps XFA's, it will be beautiful
to have a (Multi)View of this kind of format in an intuition window !)
Thank you for reading and supporting.
Feel free to contact me for suggestions/improvements/questions.
I MUST remember that XFA animations can be possible only thanks to Amiga
custom chips and its fantastic OS (...that's the way it is, mr. big blue)
Last-Last-Last: Italy is full of great Amiga talents but I really want
to make a special thank to Fabio Rotondo for writing XFA_Util 2 (no more
excuses, the docs are here, now it's on you !)
Banner:
//
\X/ Amiga. Computers for Thinking people
------------------------------------
Michele Puccini
******************************************************************************
(sorry: No AutoDocs &| AmigaGuide this time)
**** History ****
v1.0:
First release, official X-DVE 2.0 compression library
**** ToDo *****
Allow the use of XFA_LibErr() to detect errors
**** CPU-68000 WARNING ****
Developer's package includes library versions compiled for 68000/20/30/40.
Animations packed with 68020+ libraries CANNOT BE PLAYED on a standard
68000 cpu, because of data alignment restrictions (you'll get an address
error).
So, if you want to play XFA animations on a basic 68000 Amiga, you must
compress them with xfa.library for 68000 processors, that automatically
generates 68000-compatible anims.
Note that 68020,030,040 libraries are equivalent in size and code (I use
no FPU code inside, (and no 680x0 specific code...)).
**** EXAMPLES AND SUPPORT CODE ****
The example code is written in BlitzII which is powerful, simple and very
near to C (well, not too much....).
I suppose there will be no problems for C coders to read and understand it.
C include files are supplied in the appropriate drawer but I've no time to
give them a better "Amiga-Library-Standard" look (help will be appreciated).
BlitzII include file is "LIB_XFA.BB" and must be included everytime you want
to use xfa.library.
For BlitzII users there is also "xfa.library1" file that MUST be put into
"Blitz2:blitzlibs/amigalibs" drawer, in order to get access to xfa.library
functions (DefLibs MUST also be updated with the MakeDefLibs proggie).
**** SPEED DEMONS READ THIS ****
XFA is really an extra fast animation format and, if you believe in
miracles, you will obtain 256 colours super-hires overscan 1472x566
50fps animations with pictures floating on the screen an a basic A1200 ;)
This surely is the dream of everyone involved in video production.
If XFA could do this, I could surely take the Nobel for Computer Science !
You know that this is impossible to obtain from today's personal computers
expecially if they don't have some hot chips inside.
Amiga display chips, are really the best for video applications, but they
have to be updated, just to follow today's users requirements.
If they were light years away from the silly CGA, they now suffer of some
bottlenecks (slow clock, cpu stealing, dma saturation).
Now figure this:
to play an animation at 50fps you have to unpack 1 frame every 1/50s.
If the animation is a simple 640x512x4bpl resolution, the maximum thoughput
you have to substain is 640/8 * 512 * 4 bytes per 1/50s (163840 bytes) or
8.192.000 bytes/s.
If the same animation is a 768x566x8bpl resolution througput is 21.734.400
bytes/s.
If you have a 1472x566x8bpl maximum througput is 41.657.600 bytes/s.
That's (nearly) all, but you have also to consider:
- if the unpack code is in chip mem, it runs much slower than in fast
- if the unpack data is in chip mem, it is accessed slower than in fast
- the destination bitmaps MUST be in chip mem
- the more the resolution displayed, the slower the cpu (video dma steals
cycles to cpu, and you cannot figure how much this is true in super-hires).
The situation can surely improve if cpu and gfxchips have separate fast clocks
and ........ but this is another story.
The main point is that HOWEVER Amiga makes full screen animations possible
while the others keep on dreaming in front of their waving stamp-size 160x160
(pre)views.
**** NOTE ****
This is the documentation of the functions included in xfa.library.
They will surely appear to you a little bit "sparse" and sometimes
lacking.
Remember that xfa.libary has been developed for X-DVE, and not for you,
so please accept some limitations (but feel free to ask me).
These library functions are not lamer-proof. This means that parameters
passed to a function are intended to be safe and consistent.
This library has been tested with MungWall and Enforcer under OS 3.0, OS 3.1,
OS2.0 and OS 2.1.
The tecniques used in this library are completely system-friendly (except
for the fast bitmap doublebuffering under OS2.0 / OS2.1: an incredible
trick to change a ViewPort's BitMap using a single MrgCop (don't ask me how)).
To be honest I used to peek some copper lists, but this is _for_sure_ safe
even if not much smart.
LOOK MA' ... NO ENFORCER HITS !
Suggestion: Be OS-Friendly! OS3.0+ allows to do everything you want
without low-level programming and headaches.
******************************************************************************
------------------------------------------------------------------------------
FUNCTION:
XFA_LibErr()
PROTO:
LONG __asm __saveds LIBXFA_LibErr(void);
ACTION:
Returns the error code of the last library function that caused an error.
ARGUMENTS:
BUGS:
NOTES:
Not currenlty used from xfa library (maybe the next version)
------------------------------------------------------------------------------
FUNCTION:
XFA_PackMem_W(src0,src1,dest,size,mode)
PROTO:
LONG __asm __saveds LIBXFA_PackMem_W(register __a0 UWORD * , register __a1 UWORD * , register __a2 UBYTE * , register __d0 LONG , register __d1 BOOL );
ACTION:
Packs the differencies of 2 chunks of memory in XFA format (16 bit).
Returns the size of compressed memory in bytes.
ARGUMENTS:
src0 = pointer to source memory 0
src1 = pointer to source memory 1
dest = pointer to destination user-allocated memory
size = size of "src" memory chunk to be compressed
mode = FALSE:
evaluate compressed size (safe! : it will not write to dest)
TRUE:
compress memory and write packed data to dest
BUGS:
NOTE:
This is low level function, not sensible to packmode set by XFA_SetPack().
------------------------------------------------------------------------------
FUNCTION:
XFA_PackMem_L(src0,src1,dest,size,mode)
PROTO:
LONG __asm __saveds LIBXFA_PackMem_L(register __a0 ULONG * , register __a1 ULONG * , register __a2 UBYTE * , register __d0 LONG , register __d1 BOOL );
ACTION:
Packs the differencies of 2 chunks of memory in XFA format (32 bit).
Returns the size of compressed memory in bytes.
ARGUMENTS:
src0 = pointer to source memory 0
src1 = pointer to source memory 1
dest = pointer to destination user-allocated memory
size = size of "src" memory chunk to be compressed
mode = FALSE:
evaluate compressed size (safe! : it will not write to dest)
TRUE:
compress memory and write packed data to dest
BUGS:
NOTE:
this is low level function, not sensible to packmode set by XFA_SetPack()
------------------------------------------------------------------------------
FUNCTION:
XFA_PackBitMap(sbitmap0,sbitmap1,dest,mode)
PROTO:
LONG __asm __saveds LIBXFA_PackBitMap(register __a0 struct BitMap * , register __a1 struct BitMap * , register __a2 void * , register __d0 BOOL );
ACTION:
Packs the differencies of 2 bitmaps in XFA format according to the actual
packmode set by XFA_SetPack().
Returns the size of compressed memory in bytes.
ARGUMENTS:
sbitmap0 = pointer to source bitmap 0
sbitmap1 = pointer to source bitmap 1
dest = pointer to destination user-allocated memory
mode = FALSE:
evaluate compressed size (safe! : it will not write to dest)
TRUE:
compress memory and write packed data to dest
BUGS:
NOTE:
Bitmaps MUST be width/height/depth identical.
------------------------------------------------------------------------------
FUNCTION:
XFA_UnPackBitMap_W(bitmap,pkdata)
PROTO:
LONG __asm LIBXFA_UnPackBitMap_W(register __a0 struct BitMap *bm, register __a1 UBYTE *pkdata);
ACTION:
Unpacks the XFA delta pkdata into a bitmap (16 bit).
Returns the address of the next byte past the end of pkdata.
ARGUMENTS:
bitmap = pointer to destination bitmap
pkdata = pointer to XFA 16 bit packed delta
BUGS:
NOTE:
This is low level function, not sensible to packmode set by XFA_SetPack().
Destination bitmap MUST be widht/height/depth identical of the one packed
in pkdata.
------------------------------------------------------------------------------
FUNCTION:
XFA_UnPackBitMap_L(bitmap,pkdata)
PROTO:
LONG __asm LIBXFA_UnPackBitMap_L(register __a0 struct BitMap *bm, register __a1 UBYTE *pkdata);
ACTION:
Unpacks the XFA delta pkdata into a bitmap (32 bit).
Returns the address of the next byte past the end of pkdata.
ARGUMENTS:
bitmap = pointer to destination bitmap
pkdata = pointer to XFA 32 bit packed delta
BUGS:
NOTE:
This is low level function, not sensible to packmode set by XFA_SetPack().
Destination bitmap MUST be widht/height/depth identical of the one packed
in pkdata.
------------------------------------------------------------------------------
FUNCTION:
XFA_UnPackBitMap(bitmap,pkdata)
PROTO:
LONG __asm __saveds LIBXFA_UnPackBitMap(register __a0 struct BitMap * , register __a1 void * );
Returns the address of the next byte past the end of pkdata.
ACTION:
Unpacks the XFA delta pkdata into a bitmap according to actual packmode.
ARGUMENTS:
bitmap = pointer to destination bitmap
pkdata = pointer to XFA packed delta
BUGS:
NOTE:
Destination bitmap MUST be widht/height/depth identical of the one packed
in pkdata.
------------------------------------------------------------------------------
FUNCTION:
XFA_SetPack(screen,packmode)
PROTO:
void __asm __saveds LIBXFA_SetPack(register __a0 struct Screen * , register __d0 LONG );
ACTION:
Sets internal memory areas according to the screen settings.
Sets the pack mode for those library functions sensible to packmode.
Fills internal XFA_Head structure according to screen settings.
Fills internal XFA_CMap structure according to screen settings.
ARGUMENTS:
screen = pointer to screen that will contain the frames to be packed
packmode = XFA_MODE#? packing mode used from library functions
BUGS:
NOTE:
This function MUST be called before starting any compression, because
it will set all the stuff needed for packing frames.
It can be called also during the packing, just to change XFA_CMap struct
(useful to make changes to palette without affecting the frames).
Due to speed and AGA display restrictions, screen's bitmap->BytesPerRow
MUST be multiple of 8 (pixel width multipe of 64).
It is NOT safe to change compression mode or screen during the packing.
------------------------------------------------------------------------------
FUNCTION:
XFA_GetPackMode()
PROTO:
LONG __asm __saveds LIBXFA_GetPackMode(void);
ACTION:
Returns the actual packmode used by the library (XFA_MODE#?).
ARGUMENTS:
BUGS:
NOTE:
------------------------------------------------------------------------------
FUNCTION:
XFA_OpenPackStuff()
PROTO:
BOOL __asm __saveds LIBXFA_OpenPackStuff(void);
ACTION:
Allocates all the stuff needed for packing a sequence of frames.
This function also tries to allocate an internal pack buffer to
speedup the packing.
Returns TRUE if allocation is OK or FALSE if something failed.
ARGUMENTS:
BUGS:
NOTE:
This function returns TRUE even if the pack buffer cannot be allocated,
because this will affect only the packing speed.
So, allocation of speedup buffer is transparent, but memory-hungry Amigas
will be surely slower on packing frames.
------------------------------------------------------------------------------
FUNCTION:
XFA_ClosePackStuff(closemode)
PROTO:
void __asm __saveds LIBXFA_ClosePackStuff(register __d0 LONG );
ACTION:
Frees all the stuff allocated by XFA_OpenPackStuff, including
the eventual pack buffer.
ARGUMENTS:
closemode = modality for closing the animation (CLOSE_#?)
BUGS:
NOTE:
It is safe to call this function, even if the pack stuff is not allocated.
Actually the animation can be closed in 2 ways:
CLOSE_BLANK:
this means that, playing the animation, it will show the last two frames
completely cleared.
CLOSE_LOOP
this means that the animation can loop continuously without any
visible jumps (ex: a spinning title).
This function will not return any value, even if it would be better to
notify the user about a possible failure in packing the last 2 frames.
Note that CLOSE_LOOP mode, cannot close XFA_MODEI animations correcly when
there is a odd number of frames in memory.
The reason for this is very simple, as XFA_MODEI animations work with
screens divided in odd/even frames and to loop such animations, frames
must match odd/even sequence every loop.
An example ?:
incorrect sequence (odd number of frames):
frame0 frame1 frame2 frame2 frame3
odd even odd even odd
(error, next loop you'll get another odd frame)
correct sequence (even number of frames):
frame0 frame1 frame2 frame2
odd even odd even
(ok, next loop you'll get the right odd frame)
------------------------------------------------------------------------------
FUNCTION:
XFA_SetFramesArray(framesarray,numframes)
PROTO:
void __asm __saveds LIBXFA_SetFramesArray(register __a0 struct Mem * , register __d0 LONG );
ACTION:
Tells the library to use an extenal frames array.
ARGUMENTS:
framesarray = pointer to an externally allocated frames array
numframes = number of frames that can be handled from the library
(and the size of the frames array)
BUGS:
NOTE:
This function can be used if you want to have a custom frames sequence
or multiple frames sequencies in memory.
You also must take care of eventual deallocation of the frames array,
as XFA_FreeFrames cannot be used for this purpose (well, you can use it
if you allocate the frames array with AllocVec, but its is a trick and
can cause future incompatibility problems).
This function overwrites internal frames array pointer, so take care of
it, or you'll loose memory and animations.
------------------------------------------------------------------------------
FUNCTION:
XFA_AllocFrames(numframes)
PROTO:
struct Mem * __asm __saveds LIBXFA_AllocFrames(register __d0 LONG );
ACTION:
Allocates a frames array for pack or play.
Returns the (struct Mem *) pointer to the frames array or NULL if
allocation failed.
ARGUMENTS:
numframes = number of frames that can be handled from the library
(and the size of the frames array)
BUGS:
NOTE:
It is allowed to allocate multiple frames arrays with this function,
since it does not free the currently used one.
If using this feature you MUST remember all the allocations done, in order
to free them before exiting the program.
------------------------------------------------------------------------------
FUNCTION:
XFA_FreeFrames()
PROTO:
void __asm __saveds LIBXFA_FreeFrames(void);
ACTION:
Free all the currently used animation frames (linked to frames array)
and the frames array created with XFA_AllocFrames().
ARGUMENTS:
BUGS:
NOTE:
It is safe to call this, even if there is no frames array.
If you have multiple frames arrays, allocated with XFA_AllocFrames(),
you have some possibilities to free them:
suppose you have anim1 and anim2 allocated with XFA_AllocFrames()
1)
XFA_SetFramesArray(anim1,anim1frames);
XFA_FreeFrames();
XFA_SetFramesArray(anim2,anim2frames);
XFA_FreeFrames();
2)
XFA_SetFramesArray(anim1,anim1frames);
XFA_FreeAnim();
FreeVec(anim1); /* yes, you can, because XFA_AllocFrames() uses AllocVec() */
XFA_SetFramesArray(anim2,anim2frames);
XFA_FreeAnim();
FreeVec(anim2); /* yes, you can, because XFA_AllocFrames() uses AllocVec() */
------------------------------------------------------------------------------
FUNCTION:
XFA_FreeAnim()
PROTO:
void __asm __saveds LIBXFA_FreeAnim(void);
ACTION:
Frees all the currently used animation frames (linked to frames array)
but leaves the frames array allocated.
ARGUMENTS:
BUGS:
NOTE:
It is safe to call this, even if there is no frames array.
------------------------------------------------------------------------------
FUNCTION:
XFA_AnimMem()
PROTO:
LONG __asm __saveds LIBXFA_AnimMem(void);
ACTION:
Returns the size in bytes of the animation currently in memory.
ARGUMENTS:
BUGS:
NOTE:
It is safe to call this, even if there is no frames array.
------------------------------------------------------------------------------
FUNCTION:
XFA_AnimFrames()
PROTO:
LONG __asm __saveds LIBXFA_AnimFrames(void);
ACTION:
Returns the size in frames of the animation currently in memory.
ARGUMENTS:
BUGS:
NOTE:
It is safe to call this, even if there is no frames array.
------------------------------------------------------------------------------
FUNCTION:
XFA_SaveAnim(filename)
PROTO:
LONG __asm __saveds LIBXFA_SaveAnim(register __a0 char * );
ACTION:
Save the animation held into current frames array in IFF-XFA format.
Returns 0 if OK or iff.library error code (IFFERR_#?).
ARGUMENTS:
filename = complete path and filename of destination file
BUGS:
NOTE:
------------------------------------------------------------------------------
FUNCTION:
XFA_LoadAnim(filename,xfa_head,xfa_cmap,mode)
PROTO:
LONG __asm __saveds LIBXFA_LoadAnim(register __a0 char * , register __a1 struct XFA_Head * , register __a2 struct XFA_CMap * , register __d0 BOOL );
ACTION:
Multi function IFF-XFA load routine that allows to:
- check if filename is IFF-XFA
- load an animation into frames array
- load only xfa_head and xfa_cmap from an IFF-XFA animation
Returns 0 if OK or iff.library error code (IFFERR_#?).
ARGUMENTS:
filename = complete path and filename of source file
xfa_head = pointer to user's allocated XFA_Head structure
NULL to use internal library-allocated one.
xfa_cmap = pointer to user's allocated XFA_CMap structure
NULL to use internal library-allocated one.
mode = TRUE to load the whole animation
FALSE to load only xfa_head and xfa_cmap
BUGS:
NOTE:
If mode = TRUE, this function replaces any animation already in memory
issuing a XFA_FreeAnim() before loading the frames.
The animation will be loaded until there is space into frames-array
or in memory.
If you don't know the size (in frames) of the animation to be loaded,
it is a good thing to first get its xfa_head and allocate enogh frames
to load it all (reading the needed amount of frames from xfa_head->NFrames).
You can easily read the palette of an xfa animation simply putting your
own XFA_CMap pointer into the right parameter, before calling XFA_LoadAnim().
Note also that current packmode can be changed from this function, even if
it fails to load an animation.
------------------------------------------------------------------------------
FUNCTION:
XFA_PosOnFrame(frame)
PROTO:
void __asm __saveds LIBXFA_PosOnFrame(register __d0 LONG );
ACTION:
Inits internal buffers for subsequential XFA_PutFrame() calls.
Returns TRUE if OK or FALSE if it cannot init buffers (no memory or frame
out of range).
ARGUMENTS:
frame = number of frame to position to
BUGS:
NOTE:
Please refer to examples.
------------------------------------------------------------------------------
FUNCTION:
XFA_PutFrame(frame)
PROTO:
BOOL __asm __saveds LIBXFA_PutFrame(register __d0 LONG );
ACTION:
Compresses the frame and puts it in the frames array.
Returns TRUE if OK or FALSE if it cannot compress the frame (no memory
or frame out of range).
ARGUMENTS:
frame = number of frame to work on
BUGS:
NOTE:
This function also prepares internal buffers for a subsequential call to
XFA_PutFrame(), so there's no need to issue a XFA_PosOnFrame() for each
frame.
This can be done only with sequential frames.
To put frames into the frames array randomly, a XFA_PosOnFrame(f) must
be issued before every XFA_PutFrame(f).
If packmode if 16BitI or 32BitI, extra unused rasterlines will be cleared
automatically before compressing the frame.
This is a litte example of how to pack two sequencies of frames:
.
.
.
c = 6
XFA_PosOnFrame(c);
/* render here */
XFA_PutFrame(c); c++;
/* render here */
XFA_PutFrame(c); c++;
/* render here */
XFA_PutFrame(c); c++;
/* render here */
XFA_PutFrame(c); c++;
/* render here */
XFA_PutFrame(c); c++;
.
.
c = 40
XFA_PosOnFrame(c);
/* render here */
XFA_PutFrame(c); c++;
/* render here */
XFA_PutFrame(c); c++;
/* render here */
XFA_PutFrame(c); c++;
/* render here */
XFA_PutFrame(c); c++;
/* render here */
XFA_PutFrame(c); c++;
.
.
Please refer to examples.
------------------------------------------------------------------------------
FUNCTION:
XFA_PutSkip(frame)
PROTO:
BOOL __asm __saveds LIBXFA_PutSkip(register __d0 LONG );
ACTION:
Puts a skip (no delta information) frame into the frames array.
Frees any other previous information in that frames array position.
Returns TRUE if OK or FALSE if it fails (no memory or frame out of
range).
ARGUMENTS:
frame = number of frame to work on
BUGS:
NOTE:
This function is used internally by X-DVE but can be useful to init all
the frames array with the predefined skip value for current pack screen.
As definition, a skip frame will be ignored during decompression, even
if it will be considered for timings as a delay of 1/50 of sec (1/60
for NTSC).
------------------------------------------------------------------------------
FUNCTION:
XFA_IsSkip(frame)
PROTO:
BOOL __asm __saveds LIBXFA_IsSkip(register __d0 LONG );
ACTION:
Returns TRUE if the frame is a skip (ignore, no delta information) one.
ARGUMENTS:
frame = number of frame to work on
BUGS:
NOTE:
This function is used internally from X-DVE.
------------------------------------------------------------------------------
FUNCTION:
XFA_Play(loop,autopause,waitstart)
PROTO:
BOOL __asm __saveds LIBXFA_Play(register __d0 BOOL , register __d1 BOOL , register __d2 BOOL );
ACTION:
Executes the animation stored in the frames array.
Returns TRUE if ok or (only under OS3.0+) FALSE if it cannot allocate
the required DBufInfo structure.
ARGUMENTS:
loop = Infinite loop mode.
TRUE: does an infinite loop play.
FALSE: does a single shot play.
autopause = Pause mode.
TRUE: pauses the animation automatically everytime there are
no objects moving on the screen.
FALSE: executes the animation respecting the real animation
timings.
waitstart = User start mode.
TRUE: start to play only when the user clicks and releases
the left mouse button.
FALSE: starts to play immediately, without waiting.
BUGS:
NOTE:
This function temporarily disables all the multitasking facilities of
Amiga Operating System: Use with care.
During the play, mouse buttons can be used as follows:
Left Mouse Button: start the animation
restart from an autopause
if autopause = false : pause execution until release
Right Mouse Button: exit the animation if in autopause
if autopause = false and Left Mouse Button : exit the
animation
Rather complex to explain, intuitive during play.
------------------------------------------------------------------------------
FUNCTION:
XFA_UseHead(xfa_head)
PROTO:
void __asm __saveds LIBXFA_UseHead(register __a0 struct XFA_Head * );
ACTION:
'Uses' the supplied xfa_head settings.
ARGUMENTS:
xfa_head = pointer to user's XFA_Head structure
if NULL, use internally handled structure.
BUGS:
NOTE:
This function is here for completeness, and can be modified in the next
issues of the library.
Actually it simply sets internal packmode according to XFA_Head.Flags
bits.
However, it can be used when you have multiple XFA_Head structures to refer
to.
------------------------------------------------------------------------------
FUNCTION:
XFA_UseCMap(screen,xfa_cmap)
PROTO:
void __asm __saveds LIBXFA_UseCMap(register __a0 struct Screen * , register __a1 struct XFA_CMap * );
ACTION:
'Uses' supplied xfa_cmap settings on the screen.
ARGUMENTS:
screen = pointer to user's screen where XFA_CMap must be applied
if NULL, use destination XFA_SetPack() screen.
xfa_cmap = pointer to user's XFA_CMap structure
if NULL, use internally handled structure.
BUGS:
NOTE:
This function is here for completeness, and can be modified in the next
issues of the library.
Actually it simply applies the palette in XFA_CMap to the screen.
It is safe only to call this function inside a XFA_OpenPackStuff() -
XFA_ClosePackStuff(), and you must take care if the destination screen
is opened.
------------------------------------------------------------------------------
FUNCTION:
XFA_OpenPlayStuff(wbmodeid)
PROTO:
BOOL __asm __saveds LIBXFA_OpenPlayStuff(DREG0 BOOL wbmodeid);
ACTION:
Allocates and inits all the stuff needed to play a sequence of frames,
referring to the settings in XFA_Head, XFA_CMap internal structures.
Returns TRUE if OK or FALSE if function fails to open the play screen
and double buffering bitmaps.
ARGUMENTS:
wbmodeid = force a wb-like screen
TRUE: open play stuff forcing the output on a workbench-like
mode id.
FALSE: open play stuff forcing the output on a PAL screen.
BUGS:
NOTE:
This function fails if there is not enough memory to allocate the
required play stuff.
Forcing a wb-like screen, can be useful for viewing animations on Amigas
that cannot display PAL videomodes (attached to a VGA only monitor,for
example).
This means that xfa animations will be played according to wb display
refresh frequency and overscan, but they may appear too much fast and
sometimes out of the display clip boundaries.
Under OS 3.0+ this function uses the BestModeID() when forcing a wb-like
mode, while OS 2.0+ users (upgrade your OS !) will sometimes get worse
results (have you upgraded ?).
It is NOT safe to call this function if internal library-allocated XFA_Head
and XFA_CMap structures are not correctly initialized.
------------------------------------------------------------------------------
FUNCTION:
XFA_ClosePlayStuff()
PROTO:
void __asm __saveds LIBXFA_ClosePlayStuff(void);
ACTION:
Frees all the stuff opened by XFA_OpenPlayStuff().
ARGUMENTS:
BUGS:
NOTE:
It is safe to call this function, even if play stuff does not exist.
------------------------------------------------------------------------------
FUNCTION:
XFA_HeadPtr()
PROTO:
struct XFA_Head * __asm __saveds LIBXFA_HeadPtr(void);
ACTION:
Returns the internal library-allocated XFA_Head structure pointer.
ARGUMENTS:
BUGS:
NOTE:
Useful to READ XFA_Head settings (WRITING into this structure is really
dangerous, expecially having already an animation in memory).
------------------------------------------------------------------------------
FUNCTION:
XFA_CMapPtr()
PROTO:
struct XFA_CMap * __asm __saveds LIBXFA_CMapPtr(void);
ACTION:
Returns the internal library-allocated XFA_CMap structure pointer.
ARGUMENTS:
BUGS:
NOTE:
Useful to READ XFA_CMap settings (WRITING into this structure is not
too dangerous, but can be easily avoided in order to change animation's
palette. See XFA_SetPack() function).
------------------------------------------------------------------------------
FUNCTION:
XFA_ChangePackBitMap(bitmap)
PROTO:
void __asm __saveds LIBXFA_ChangePackBitMap(register __a0 struct BitMap * );
ACTION:
Changes the internal source bitmap pointer which PosOnFrame(), PutFrame(),
PutSeqFrame() refer for packing a frame.
ARGUMENTS:
bitmap = pointer to the new source bitmap
BUGS:
NOTE:
This function is here to allow the packing of double (or more) buffered
animations (like Anim5/7/x) whose frames must be unpacked into 2 different
bitmaps (one for the even, one for the odd frame).
Please, refer to the examples.
------------------------------------------------------------------------------
FUNCTION:
XFA_PutSeqFrame(frame)
PROTO:
BOOL __asm __saveds LIBXFA_PutSeqFrame(register __d0 LONG );
ACTION:
Compresses the frame and puts it in the frames array.
Returns TRUE if OK or FALSE if it cannot compress the frame (no memory
or frame out of range).
ARGUMENTS:
frame = number of frame to work on
BUGS:
NOTE:
The differencies from XFA_PutFrame() ?
XFA_PutFrame() in conjunction with XFA_PosOnFrame() allows easy random
access for packing xfa animations.
This function is here to help the handling of sequential-only problems
like anim5/7/x to xfa conversions.
XFA_PutFrame() does some undesired stuff that is both unuseful and
incorrect to solve the above problem, so that's why XFA_PutSeqFrame()
is here.
XFA_PutSeqFrame() keeps track of the previous odd/even frames automatically,
so there's no need for the users to do this.
This function also prepares internal buffers for a subsequential call to
XFA_PutSeqFrame(), so there's no need to issue a XFA_PosOnFrame() for each
frame.
If packmode if 16BitI or 32BitI, extra unused rasterlines will be cleared
automatically before compressing the frame.
Please refer to examples.
------------------------------------------------------------------------------
FUNCTION:
XFA_SaveScreen(screen,filename)
PROTO:
LONG __asm __saveds LIBXFA_SaveScreen(register __a0 struct Screen * , register __a1 char * );
ACTION:
Saves a standard Amiga screen in IFF-ILBM format.
Returns 0 if OK or iff.library error code (IFFERR_#?).
ARGUMENTS:
screen = pointer to the screen to save
filename = name of the iff file to write
BUGS:
NOTE:
This function is here for completeness.
IFF-ILBM write code is the one furnished from CBM in NewIff39 archive.
For this reason, I don't know if it's fully bug free or not.
If you have faith in Carolynn Scheppner, the mother of all ilbm
handlers .........
------------------------------------------------------------------------------
FUNCTION:
XFA_OpenRead(filename,head,cmap)
PROTO:
struct IFFHandle * __asm __saveds LIBXFA_OpenRead(register __a0 char * , register __a1 struct XFA_Head * , register __a2 struct XFA_CMap * );
ACTION:
This function performs the following actions:
- opens an XFA file for reading.
- (if file is xfa) loads XFA_Head and XFA_Cmap chunks.
- (if file is xfa) sets current packmode for library functions.
Returns a pointer to an IFFHandle struct.
Returns NULL if it fails to open the file or if the file is not xfa.
ARGUMENTS:
filename = complete path and filename of source xfa file
xfa_head = pointer to user's allocated XFA_Head structure
NULL to use internal library-allocated one.
xfa_cmap = pointer to user's allocated XFA_CMap structure
NULL to use internal library-allocated one.
BUGS:
NOTE:
------------------------------------------------------------------------------
FUNCTION:
XFA_ReadFrame(iff,mem)
PROTO:
LONG __asm __saveds LIBXFA_ReadFrame(register __a0 struct IFFHandle * , register __a1 struct Mem * );
ACTION:
Reads a single xfa frame from the stream allocating enough ram to store it.
Returns 0 if OK or iff.library error code (IFFERR_#?).
ARGUMENTS:
iff = pointer to a valid IFFHandle (possibly opened with XFA_OpenRead())
mem = pointer to a previously allocated mem structure where this function
will set all appropriate fields.
BUGS:
NOTE:
This function allocates memory, so take care of freeing every loaded
frame as soon as you've used it.
------------------------------------------------------------------------------
FUNCTION:
XFA_FreeFrame(mem)
PROTO:
void __asm __saveds LIBXFA_FreeFrame(register __a0 struct Mem * );
ACTION:
Frees a single xfa frame from memory
ARGUMENTS:
mem = pointer to a previously allocated mem structure indicating the
frame in memory.
BUGS:
NOTE:
As Mem structure will probabily grow or change, you are kindly requested
to make use of this function instead of trying to free frames with your
own code.
This will ensure future compatibility with new releases of xfa.library.
Internal sanity check covers only NULL mem->Ptr fields, but I have to remind
you that all arguments are intended to be safe and consistent.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
LAST MINUTE CHANGES
- Added support for NTSC screens.
- Added OSCAN_VIDEO flag to OpenPlayStuff() code.
- current version is 1.10.
------------------------------------------------------------------------------
<EOF>